1
2
Kolejny
Mówiąc najprościej, git pull wykonuje pobieranie git, a następnie scalanie git.
W dowolnym momencie możesz wykonać pobieranie git, aby zaktualizować gałęzie zdalnego śledzenia w sekcji refs / remotes / /.
Ta operacja nigdy nie zmienia żadnego z twoich lokalnych oddziałów w ramach refs / heads i można ją bezpiecznie wykonać bez zmiany kopii roboczej. Słyszałem nawet o osobach uruchamiających git fetch okresowo w pracy cron w tle (chociaż nie polecałbym tego robić).
Git pull jest tym, co można zrobić, aby zaktualizować lokalny oddział o jego zdalną wersję, jednocześnie aktualizując inne gałęzie zdalnego śledzenia.
Z dokumentacji Git dla git pull:
W swoim domyślnym trybie, git pull jest skrótem dla git fetch, po którym następuje git merge FETCH_HEAD.
|
Kiedy używasz pull, Git próbuje automatycznie wykonać twoją pracę za ciebie. Jest zależny od kontekstu, więc Git połączy wszystkie ściągnięte zatwierdzenia z gałęzią, w której aktualnie pracujesz. Pull automatycznie łączy zatwierdzenia bez uprzedniego ich przeglądania. Jeśli nie zarządzasz ściśle swoimi oddziałami, możesz napotkać częste konflikty.
Kiedy pobierasz, Git zbiera wszystkie zatwierdzenia z gałęzi docelowej, które nie istnieją w twojej bieżącej gałęzi i przechowuje je w lokalnym repozytorium. Jednak nie łączy ich z bieżącą gałęzią. Jest to szczególnie przydatne, jeśli chcesz aktualizować repozytorium, ale pracujesz nad czymś, co może się zepsuć, jeśli zaktualizujesz swoje pliki.
Aby zintegrować commity z twoją główną gałęzią, używasz merge.
|
Ważne jest, aby zestawić filozofię projektowania git z filozofią bardziej tradycyjnego narzędzia do kontroli źródła, takiego jak SVN.
Subversion został zaprojektowany i zbudowany w modelu klient / serwer. Istnieje jedno repozytorium, którym jest serwer, a kilku klientów może pobierać kod z serwera, pracować nad nim, a następnie przesłać go z powrotem na serwer. Założenie jest takie, że klient zawsze może skontaktować się z serwerem, gdy musi wykonać operację.
Git został zaprojektowany do obsługi bardziej rozproszonego modelu bez potrzeby posiadania centralnego repozytorium (choć z pewnością możesz go użyć, jeśli chcesz). Również git został zaprojektowany tak, aby klient i „serwer” nie musieli być online w tym samym czasie. Git został zaprojektowany tak, aby osoby korzystające z niewiarygodnego łącza mogły wymieniać kod nawet przez e-mail. Istnieje możliwość pracy całkowicie odłączonej i wypalenia płyty CD w celu wymiany kodu przez git.
Aby wspierać ten model, git utrzymuje lokalne repozytorium z Twoim kodem, a także dodatkowe lokalne repozytorium, które odzwierciedla stan zdalnego repozytorium. Przechowując lokalnie kopię zdalnego repozytorium, git może określić potrzebne zmiany, nawet jeśli zdalne repozytorium jest nieosiągalne. Później, gdy będziesz musiał wysłać zmiany do kogoś innego, git może przesłać je jako zestaw zmian z punktu w czasie znanego zdalnemu repozytorium.
git fetch to polecenie, które mówi „zaktualizuj moją lokalną kopię zdalnego repozytorium”.
git pull mówi „przenieś zmiany w zdalnym repozytorium do miejsca, w którym trzymam swój własny kod”.
Zwykle git pull robi to, wykonując git fetch, aby zaktualizować lokalną kopię zdalnego repozytorium, a następnie scalając zmiany z własnym repozytorium kodu i prawdopodobnie kopią roboczą.
Na wynos należy pamiętać, że często na stacji roboczej znajdują się co najmniej trzy kopie projektu. Jedna kopia to Twoje własne repozytorium z własną historią zmian. Druga kopia to kopia robocza, w której edytujesz i budujesz. Trzecia kopia to lokalna "buforowana" kopia zdalnego repozytorium.
|
Oto obraz Olivera Steele pokazujący, jak to wszystko do siebie pasuje:
Jeśli zainteresowanie jest wystarczające, przypuszczam, że mógłbym zaktualizować obraz, aby dodać git clone i git merge ...
|
Jednym z przypadków użycia git fetch jest to, że poniższe informacje poinformują Cię o wszelkich zmianach w zdalnej gałęzi od ostatniego ściągnięcia ... więc możesz sprawdzić przed wykonaniem faktycznego ściągnięcia, które może zmienić pliki w bieżącej gałęzi i kopii roboczej.
git fetch
git diff ... pochodzenie
Zobacz: https://git-scm.com/docs/git-diff dotyczące składni podwójnej i potrójnej kropki w poleceniu diff
|
Trochę mnie kosztowało zrozumienie, jaka jest różnica, ale to jest proste wyjaśnienie. master w twoim lokalnym hoście to gałąź.
Kiedy klonujesz repozytorium, pobierasz całe repozytorium do lokalnego hosta. Oznacza to, że w tym czasie masz wskaźnik początku / wzorca do HEAD i wzorca wskazującego na tę samą HEAD.
kiedy zaczynasz pracę i dokonujesz zatwierdzeń, przesuwasz główny wskaźnik do HEAD + twoje zatwierdzenia. Ale wskaźnik pochodzenia / wzorca nadal wskazuje, co to było podczas klonowania.
Więc różnica będzie wyglądać tak:
Jeśli wykonasz pobieranie git, po prostu pobierze wszystkie zmiany w zdalnym repozytorium (GitHub) i przeniesie wskaźnik pochodzenia / wzorca do HEAD. W międzyczasie kierownik lokalnego oddziału będzie wskazywał, gdzie się znajduje.
Jeśli wykonasz polecenie git pull, w zasadzie pobierze (jak wyjaśniono wcześniej) i scali wszelkie nowe zmiany w twoimmaster i przesuń wskaźnik do HEAD.
|
Czasami pomaga reprezentacja wizualna.
|
Krótko
Pobieranie git jest podobne do ściągania, ale nie łączy się. tj. pobiera zdalne aktualizacje (odniesienia i obiekty), ale lokalna pozostaje taka sama (tj. źródło / wzorzec zostaje zaktualizowany, ale główny pozostaje taki sam).
git pull ściąga z pilota i natychmiast łączy.
Jeszcze
git clone klonuje repozytorium.
git rebase zapisuje rzeczy z twojej aktualnej gałęzi, która nie znajduje się w gałęzi upstream, do tymczasowego obszaru. Twoja gałąź jest teraz taka sama, jak przed rozpoczęciem zmian. Tak więc, git pull -rebase usunie zdalne zmiany, przewinie lokalny oddział, odtworzy zmiany na górze bieżącej gałęzi jeden po drugim, aż będziesz na bieżąco.
Ponadto git branch -a pokaże ci dokładnie, co się dzieje ze wszystkimi twoimi oddziałami - lokalnymi i zdalnymi.
Ten post na blogu był przydatny:
Różnica między git pull, git fetch i git clone (i git rebase) - Mike Pearce
i obejmuje git pull, git fetch, git clone i git rebase.
====
AKTUALIZACJA
Pomyślałem, że zaktualizuję to, aby pokazać, jak faktycznie wykorzystasz to w praktyce.
Zaktualizuj lokalne repozytorium z poziomu zdalnego (ale nie scalaj):
git fetch
Po pobraniu aktualizacji zobaczmy różnice:
git diff master origin / master
Jeśli jesteś zadowolony z tych aktualizacji, scal:
git pull
Uwagi:
W kroku 2: Aby uzyskać więcej informacji na temat różnic między lokalnymi a zdalnymi zdalnymi, zobacz: Jak porównać lokalną gałąź git z jej zdalną gałęzią?
W kroku 3: Prawdopodobnie dokładniejsze (np. W przypadku szybko zmieniającego się repozytorium) jest zrobienie źródła git rebase tutaj. Zobacz komentarz @Justin Ohms w innej odpowiedzi.
Zobacz też: http://longair.net/blog/2009/04/16/git-fetch-and-merge/
|
git-pull - Pobierz z innego repozytorium lub lokalnego oddziału i połącz z nim
STRESZCZENIE
git pull…
OPIS
Uruchamia git-fetch z podanymi parametrami i wywołuje git-merge, aby scalić plik
pobrane głowy do bieżącej gałęzi. Z --rebase wywołuje git-rebase
zamiast git-merge.
Pamiętaj, że możesz użyć. (bieżący katalog) jako do ściągnięcia
z lokalnego repozytorium - jest to przydatne przy łączeniu lokalnych oddziałów
do bieżącej gałęzi.
Zauważ również, że opcje przeznaczone dla samego git-pull i bazowego git-merge
należy podać przed opcjami przeznaczonymi do pobierania git.
Wyciągnąłbyś, gdybyś chciał scalić historie, pobrałbyś, gdybyś po prostu „chciał kodez”, ponieważ jakaś osoba oznaczała tutaj niektóre artykuły.
|
Możesz pobrać ze zdalnego repozytorium, zobaczyć różnice, a następnie pobrać lub scalić.
To jest przykład zdalnego repozytorium o nazwie origin i branch o nazwie master, który śledzi źródło / master zdalnej gałęzi:
git checkout master
git fetch
git diff pochodzenie / wzorzec
git rebase origin master
|
Krótka i łatwa odpowiedź jest taka, że git pull to po prostu git fetch, po którym następuje git merge.
Bardzo ważne jest, aby pamiętać, że git pull automatycznie połączy się, czy ci się to podoba, czy nie. Może to oczywiście doprowadzić do konfliktów scalania. Powiedzmy, że twój pilot to źródło, a twoja gałąź to master. Jeśli git diff origin / master przed ściągnięciem, powinieneś mieć pojęcie o potencjalnych konfliktach podczas łączenia i możesz odpowiednio przygotować lokalny oddział.
Oprócz ciągnięcia i pchania, niektóre przepływy pracy obejmują git rebase, na przykład ten, który parafrazuję z połączonego artykułu:
git pull origin master
git checkout foo-branch
git rebase master
git push origin foo-branch
Jeśli znajdziesz się w takiej sytuacji, możesz ulec pokusie, aby git pull --rebase. Chyba że naprawdę, naprawdę wiesz, co robisz, odradzałbym to. To ostrzeżenie pochodzi ze strony podręcznika man dla git-pull, wersja 2.3.5:
Jest to potencjalnie niebezpieczny tryb działania. Przepisuje
historii, co nie wróży dobrze, kiedy publikujesz tę historię
już. Nie używaj tej opcji, chyba że przeczytałeś git-rebase (1)
ostrożnie.
|
OK, oto kilka informacji o git pull i git fetch, abyś mógł zrozumieć rzeczywiste różnice ... w kilku prostych słowach, pobieranie pobiera najnowsze dane, ale nie zmienia kodu i nie ma zamiaru zepsuć aktualnego kodu lokalnego oddziału , ale ściągnij, pobierz zmiany w kodzie i połącz je z lokalnym oddziałem, czytaj dalej, aby uzyskać więcej informacji o każdym z nich:
git fetch
Ściągnie wszystkie referencje i obiekty oraz wszelkie nowe gałęzie do lokalnego repozytorium ...
Pobierz gałęzie i / lub tagi (zbiorczo „referencje”) z co najmniej jednego
inne repozytoria wraz z obiektami niezbędnymi do ich uzupełnienia
historie. Oddziały zdalnego śledzenia są aktualizowane (patrz opis
poniżej, aby poznać sposoby kontrolowania tego zachowania).
Domyślnie każdy znacznik wskazujący na pobierane historie to
również pobrane; efektem jest pobranie znaczników wskazujących na gałęzie, które
jesteś zainteresowany. To domyślne zachowanie można zmienić za pomocą
opcje --tags lub --no-tags lub konfigurując
zdalne..tagOpt. Używając refspec, który bezpośrednio pobiera tagi,
możesz pobrać tagi, które nie wskazują na interesujące Cię gałęzie
w jak również.
git fetch może pobrać zjedno nazwane repozytorium lub adres URL, lub
z kilku repozytoriów jednocześnie, jeśli podano i istnieje plik
piloty. wpis w pliku konfiguracyjnym. (Zobacz git-config1).
Jeśli nie określono pilota, domyślnie będzie to pilot źródłowy
używany, chyba że dla bieżącego skonfigurowana jest gałąź upstream
gałąź.
Nazwy pobieranych referencji wraz z nazwami obiektów
wskazują na, są zapisywane do .git / FETCH_HEAD. Ta informacja może być
używany przez skrypty lub inne polecenia git, takie jak git-pull.
git pull
Zastosuje zmiany ze zdalnego do bieżącego oddziału w lokalnym ...
Włącza zmiany ze zdalnego repozytorium do bieżącej gałęzi.
W swoim domyślnym trybie, git pull jest skrótem dla git fetch, po którym następuje
git merge FETCH_HEAD.
Dokładniej, git pull uruchamia git fetch z podanymi parametrami i
wywołuje git merge, aby scalić pobrane głowice gałęzi z bieżącą
gałąź. Z --rebase uruchamia git rebase zamiast git merge.
powinna być nazwą zdalnego repozytorium przekazaną do
git-fetch1. może nazwać dowolny zdalny odnośnik (na przykład
nazwa tagu) lub nawet zbiór odnośników z odpowiednimi
oddziały zdalnego śledzenia (np. refs / heads /: refs / remotes / origin /),
ale zwykle jest to nazwa gałęzi w zdalnym repozytorium.
Wartości domyślne i są odczytywane z pliku
Konfiguracja „zdalna” i „scalająca” dla bieżącej gałęzi zgodnie z ustawieniami
git-branch --track.
Tworzę również poniższą wizualizację, aby pokazać, jak git fetch i git pull współpracują ...
|
Ta interaktywna reprezentacja graficzna jest bardzo pomocna w zrozumieniu git: http://ndpsoftware.com/git-cheatsheet.html
git fetch po prostu „pobiera” zmiany z pilota do lokalnego repozytorium. git pull pobiera zmiany i łączy je z bieżącą gałęzią. „W trybie domyślnym git pull to skrót od git fetch, po którym następuje git merge FETCH_HEAD.”
|
Premia:
Mówiąc o pull & fetch w powyższych odpowiedziach, chciałbym podzielić się ciekawą sztuczką,
git pull --rebase
Powyższe polecenie jest najbardziej użytecznym poleceniem w moim życiu gita, które pozwoliło zaoszczędzić mnóstwo czasu.
Przed wysłaniem nowych zatwierdzeń do serwera wypróbuj to polecenie, a automatycznie zsynchronizuje najnowsze zmiany na serwerze (z funkcją pobierania + scalania) i umieści Twoje zatwierdzenie na górze w dzienniku git. Nie musisz się martwić o ręczne ściąganie / scalanie.
Znajdź szczegóły na: http://gitolite.com/git-pull--rebase
|
Lubię mieć wizualną reprezentację sytuacji, aby uchwycić te rzeczy. Może inni programiści też chcieliby to zobaczyć, więc oto mój dodatek. Nie jestem do końca pewien, czy wszystko się zgadza, więc proszę o komentarz, jeśli znajdziesz jakieś błędy.
SYSTEM LOKALNY
. ==================================================== ===
=================. ================= =================== =============
ZDALNE REPOZYTORIUM. ZDALNY MAGAZYN LOKALNY MAGAZYN KOPIA ROBOCZA
(POCHODZENIE) . (ZACHOWANE)
na przykład, . lustro
repozytorium github. . zdalne repozytorium
Może też być .
wiele repozytoriów.
.
.
FETCH * ------------------> *
Twoja lokalna pamięć podręczna pilota jest aktualizowana o pochodzenie (lub wiele plików
źródła zewnętrzne, czyli rozproszony charakter gita)
.
CIĄGNĄĆ *------------------------------------------------ --------> *
zmiany są scalane bezpośrednio z lokalną kopią. kiedy pojawiają się konflikty,
jesteś proszony o decyzje.
.
ZATWIERDŹ. * <--------------- *
Pochodząc na przykład z wywrotu, możesz pomyśleć, że jest to zatwierdzenie
zaktualizuje źródło. W git zatwierdzenie jest wykonywane tylko w lokalnym repozytorium.
.
PUSH * <--------------------------------------- *
Synchronizuje zmiany z powrotem do źródła.
Niektóre główne zalety posiadania pobranego lustra pilota to:
Wydajność (przewijaj wszystkie zatwierdzenia i komunikaty bez próby przeciskania ich przez sieć)
Informacje zwrotne o stanie lokalnego repozytorium (na przykład używam SourceTree firmy Atlassian, które da mi żarówkę wskazującą, czy zatwierdzam zmiany z wyprzedzeniem, czy z opóźnieniem w porównaniu do źródła. Informacje te można zaktualizować za pomocą GIT FETCH).
|
Z tym też walczyłem. W rzeczywistości trafiłem tutaj z wyszukiwaniem w Google dokładnie tego samego pytania. Przeczytanie wszystkich tych odpowiedzi w końcu spowodowało, że w mojej głowie pojawił się obraz i postanowiłem spróbować rozwiązać ten problem, patrząc na stan 2 repozytoriów i 1 piaskownicy oraz czynności wykonywane w czasie podczas oglądania ich wersji. Oto co wymyśliłem. Proszę, popraw mnie, jeśli coś schrzaniłem.
Trzy repozytoria z pobraniem:
--------------------- ----------------------- ------ -----------------
- Zdalne repozytorium - - Zdalne repozytorium - - Zdalne repozytorium -
- - - zostaje popchnięty - - -
- @ R01 - - @ R02 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------------------------------
- Lokalne repozytorium - - Lokalne repozytorium - - Lokalne repozytorium -
- ciągnąć - - - - ściągać -
- @ R01 - - @ R01 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------- ------ -----------------
- Lokalna piaskownica - - Lokalna piaskownica - - Lokalna piaskownica -
- Do kasy - - nowa praca wykonana - - -
- @ R01 - - @ R01 + - - @ R01 + -
--------------------- ----------------------- ------ -----------------
Trzy repozytoria z ciągnięciem
--------------------- ----------------------- ------ -----------------
- Zdalne repozytorium - - Zdalne repozytorium - - Zdalne repozytorium -
- - - zostaje popchnięty - - -
- @ R01 - - @ R02 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------- ------ -----------------
- Lokalne repozytorium - - Lokalne repozytorium - - Lokalne repozytorium -
- ciągnąć - - - - ciągnąć -
- @ R01 - - @ R01 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------- ------ -----------------
- Lokalna piaskownica - - Lokalna piaskownica - - Lokalna piaskownica -
- Do kasy - - nowa praca wykonana - - połączona z R02 -
- @ R01 - - @ R01 + - - @ R02 + -
--------------------- ----------------------- ------ -----------------
Pomogło mi to zrozumieć, dlaczego pobieranie jest dość ważne.
|
Różnicę między GIT Fetch i GIT Pull można wyjaśnić za pomocą następującego scenariusza:
(Pamiętając, że obrazy mówią głośniej niż słowa !, przedstawiłem obrazkowe przedstawienie)
Weźmy przykład, że pracujesz nad projektem z członkami swojego zespołu. Będzie więc istniała jedna główna gałąź projektu i wszyscy współautorzy muszą ją rozwidlić do własnego repozytorium lokalnego, a następnie pracować na tej gałęzi lokalnej, aby zmodyfikować / dodać moduły, a następnie przesłać z powrotem do gałęzi głównej.
Więc,
Początkowy stan dwóch gałęzi po rozwidleniu głównego projektu w lokalnym repozytorium będzie wyglądał następująco: (A, B i C to moduły już ukończone w projekcie)
Teraz rozpocząłeś pracę nad nowym modułem (załóżmy, że D) i po ukończeniu modułu D chcesz go przenieść do głównej gałęzi, ale w międzyczasie jeden z twoich kolegów z zespołu opracował nowy moduł E, F i zmodyfikowany C.
Więc teraz to, co się stało, jest takie, że w lokalnym repozytorium brakuje oryginalnego postępu projektu, a zatem wypychanie twoich zmian do głównej gałęzi może prowadzić do konfliktu i może spowodować nieprawidłowe działanie modułu D.
Aby uniknąć takich problemów i pracować równolegle z pierwotnym postępem projektu, istnieją dwa sposoby:
1. Git Fetch - Spowoduje to pobranie wszystkich zmian, które zostały wprowadzone w projekcie pochodzenia / głównej gałęzi, których nie ma w lokalnym oddziale. I będzie czekać, aż polecenie Git Merge zastosuje zmiany, które zostały pobrane do Twojego repozytorium lub gałęzi.
Więc teraz możesz uważnie monitorować pliki przed scaleniem ich z repozytorium. Możesz także zmodyfikować D, jeśli to konieczne, ze względu na zmodyfikowany C.
2. Git Pull - spowoduje to zaktualizowanie lokalnego oddziału o gałąź początkową / główną, czyli tak naprawdę to, co robi, to połączenie Git Fetch i Git scalane jeden po drugim.
Może to jednak powodować konflikty, dlatego zaleca się używanie Git Pull z czystą kopią.
|
Po prostu mówimy:
git pull == git fetch + git merge
Jeśli uruchomisz git pull, nie musisz łączyć danych z danymi lokalnymi. Jeśli uruchomisz git fetch, oznacza to, że musisz uruchomić git merge, aby uzyskać najnowszy kod na komputerze lokalnym. W przeciwnym razie lokalny kod maszynowy nie zostałby zmieniony bez scalenia.
Więc w Git Gui, kiedy pobierasz, musisz scalić dane. Samo pobieranie nie spowoduje zmian kodu w Twoim lokalnym. Możesz to sprawdzić, aktualizując kod, pobierając
raz weź i zobacz; kod, którego nie zmieni. Następnie scalasz ... Zobaczysz zmieniony kod.
|
git fetch ściąga kod ze zdalnego serwera do gałęzi śledzenia w lokalnym repozytorium. Jeśli twój pilot nazywa się origin (domyślnie), wtedy te gałęzie będą w origin /, na przykład origin / master, origin / mybranch-123 itd. To nie są twoje obecne gałęzie, są to lokalne kopie tych gałęzi z serwera .
git pull pobiera git, ale następnie łączy kod z gałęzi śledzenia z Twoim aktualnymlokalna wersja tego oddziału. Jeśli nie jesteś jeszcze gotowy na te zmiany, po prostu najpierw pobierz git.
|
git fetch pobierze zdalne gałęzie, abyś mógł git diff lub git połączyć je z bieżącą gałęzią. git pull uruchomi pobieranie na zdalnym ramieniu śledzonym przez bieżącą gałąź, a następnie połączy wynik. Możesz użyć git fetch, aby sprawdzić, czy są jakieś aktualizacje w zdalnym oddziale bez konieczności łączenia ich z lokalnym oddziałem.
|
Git Fetch
Pobierasz zmiany do lokalnego oddziału od początku przez pobieranie. Fetch prosi zdalne repozytorium o wszystkie zatwierdzenia, które wykonali inni, ale których nie masz w lokalnym repozytorium. Fetch pobiera te zatwierdzenia i dodaje je do lokalnego repozytorium.
Git Merge
Możesz zastosować zmiany pobrane przez pobieranie za pomocą polecenia scalania. Merge weźmie zatwierdzenia pobrane z pobierania i spróbuje dodać je do lokalnego oddziału. Scalanie zachowa historię zatwierdzania zmian lokalnych, dzięki czemu po udostępnieniu gałęzi za pomocą funkcji push Git będzie wiedział, jak inni mogą scalić Twoje zmiany.
Git Pull
Fetch and Merge są uruchamiane razem na tyle często, że utworzono polecenie łączące te dwa elementy, pull. Pull pobiera, a następnie łączy w celu dodania pobranych zatwierdzeń do lokalnego oddziału.
|
Mówiąc prościej, jeśli masz zamiar wskoczyć do samolotu bez połączenia z Internetem ... przed odlotem możesz po prostu wykonać polecenie git fetch origin . Pobrałby wszystkie zmiany na twój komputer, ale trzymałby go oddzielnie od lokalnego programowania / obszaru roboczego.
W samolocie możesz wprowadzić zmiany w lokalnym obszarze roboczym, a następnie połączyć go z tym, co pobrałeś i rozwiązać potencjalne konflikty scalania bez połączenia z Internetem. I chyba, że ktoś wprowadził nowe zmiany w zdalnym repozytorium, po przybyciu na miejsce docelowe zrobiłbyś git push origin i poszedł po kawę.
Z tego niesamowitego samouczka Atlassian:
Polecenie git fetch pobiera zatwierdzenia, pliki i odwołania z pliku
zdalne repozytorium do lokalnego repozytorium.
Pobieranie to to, co robisz, gdy chcesz zobaczyć, co mają wszyscy inni
pracowałem nad. Jest podobny do aktualizacji SVN, ponieważ pozwala zobaczyć
jak rozwijała się historia centralna, ale nie zmusza cię do tego
faktycznie scal zmiany w swoim repozytorium. Git izoluje
pobrana zawartość jako z istniejącej zawartości lokalnej, ma absolutnie
bez wpływu na lokalne prace rozwojowe. Pobrana zawartość musi być jawnie wyrejestrowana za pomocą polecenia git checkout. To sprawia
pobranie bezpiecznego sposobu przeglądania zatwierdzeń przed ich integracją z
twoje lokalne repozytorium.
Podczas pobierania treści ze zdalnego repozytorium dostępne są polecenia git pull i git fetch w celu wykonania zadania. Możesz rozważyć
git pobiera „bezpieczną” wersję dwóch poleceń. Zostanie pobrany
zdalną zawartość, ale nie aktualizuj stanu pracy lokalnego repozytorium,
pozostawiając obecną pracę nienaruszoną. git pull jest bardziej agresywny
Alternatywnie, pobierze zdalną zawartość dla aktywnego lokalnego
branch i natychmiast wykonaj polecenie git merge, aby utworzyć zatwierdzenie merge
dla nowej zdalnej zawartości. Jeśli masz oczekujące zmiany w toku
spowoduje to konflikty i rozpocznie rozwiązywanie konfliktów scalania
pływ.
Z git pull:
Nie ma żadnej izolacji.
Nie musi być wyraźnie wyrejestrowany. Ponieważ niejawnie łączy git.
Etap scalania wpłynie na rozwój lokalny i może powodować konflikty
Zasadniczo NIE jest to bezpieczne. To agresywne.
W przeciwieństwie do git fetch, w którym wpływa tylko na .git / refs / remotes, git pull wpłynie zarówno na .git / refs / remotes, jak i .git / refs / heads /
Hmmm ... więc jeśli nie aktualizuję kopii roboczej za pomocą git fetch, to gdzie mam dokonać zmian? Gdzie Git pobiera zapisuje nowe zatwierdzenia?
Świetne pytanie. Umieszcza go w miejscu odizolowanym od kopii roboczej. Ale znowu gdzie? Dowiedzmy Się.
W katalogu twojego projektu (tj. Tam, gdzie wykonujesz polecenia git) wykonaj:
ls. Spowoduje to wyświetlenie plików i katalogów. Wiem, nic fajnego.
Teraz wykonaj ls -a. Spowoduje to wyświetlenie plików z kropkami, tj. Plików zaczynających się od. Będziesz wtedy mógł zobaczyć katalog o nazwie: .git.
Zrób cd .git. To oczywiście zmieni twój katalog.
Teraz zaczyna się zabawa; czy ls. Zobaczysz listę katalogów. Szukamy referencji. Zrób referencje CD.
Ciekawie jest zobaczyć, co znajduje się we wszystkich katalogach, ale skupmy się na dwóch z nich. głowice i piloty. Użyj płyty CD, aby sprawdzić również ich zawartość.
Każde pobranie git, które wykonasz, zaktualizuje elementy w katalogu /.git/refs/remotes. Nie zaktualizuje niczego w katalogu /.git/refs/heads.
Każde git pull najpierw wykona pobieranie git, zaktualizuje elementy w katalogu /.git/refs/remotes, a następnie połączy z lokalnym, a następnie zmieni nagłówek w katalogu /.git/refs/heads.
Bardzo dobrą pokrewną odpowiedź można również znaleźć w artykule Gdzie samo umieszcza się polecenie „git fetch” ?.
Poszukaj także „notacji z ukośnikiem” w poście dotyczącym konwencji nazewnictwa gałęzi Git. Pomaga lepiej zrozumieć, w jaki sposób Git umieszcza rzeczyróżne katalogi.
Aby zobaczyć rzeczywistą różnicę
Po prostu zrób:
git pobierz wzorzec pochodzenia
git checkout master
Jeśli zdalny master został zaktualizowany, otrzymasz następujący komunikat:
Twoja gałąź jest za 'origin / master' o 2 commity i może być przewijana do przodu.
(użyj „git pull”, aby zaktualizować swój lokalny oddział)
Jeśli nie pobrałeś i po prostu zrobiłeś git checkout master, twój lokalny git nie wiedziałby, że dodano 2 zatwierdzenia. I po prostu powiedziałoby:
Już na „master”
Twój oddział jest aktualny pod względem „pochodzenia / mistrza”.
Ale to jest przestarzałe i niepoprawne. Dzieje się tak, ponieważ git przekaże Ci informacje zwrotne wyłącznie na podstawie tego, co wie. Jest nieświadomy nowych zatwierdzeń, których jeszcze nie usunął ...
Czy istnieje sposób, aby zobaczyć nowe zmiany dokonane zdalnie podczas lokalnej pracy nad oddziałem?
Niektóre IDE (np.Xcode) są super inteligentne i używają wyniku pobierania git i mogą dodawać adnotacje do linii kodu, które zostały zmienione w zdalnej gałęzi Twojej bieżącej gałęzi roboczej. Jeśli ta linia została zmieniona zarówno przez lokalne zmiany, jak i zdalną gałąź, wtedy ta linia zostanie oznaczona czerwoną adnotacją. To nie jest konflikt scalania. To potencjalny konflikt scalania. To ostrzeżenie, którego możesz użyć do rozwiązania przyszłego konfliktu scalania przed wykonaniem git pull ze zdalnej gałęzi.
Zabawna wskazówka:
Jeśli pobrałeś zdalny oddział, np. zrobił:
funkcja pobierania źródła git / 123
Wtedy to trafi do twojego katalogu pilotów. Nadal nie jest dostępny w Twoim katalogu lokalnym. Jednak upraszcza to twoją kasę do tej zdalnej gałęzi przez DWIM (rób co mam na myśli):
funkcja kasy git / 123
nie musisz już robić:
git checkout -b feature / 123 origin / feature / 123
Więcej na ten temat przeczytasz tutaj
|
Jedyna różnica między git pull i git fetch jest taka, że:
git pull ściąga ze zdalnej gałęzi i scala ją.
git fetch pobiera tylko ze zdalnej gałęzi, ale nie łączy się
czyli git pull = git fetch + git merge ...
|
Git pozwala na stosowanie starszych chronologicznie zatwierdzeń po nowszych zatwierdzeniach.
Z tego powodu czynność przenoszenia zatwierdzeń między repozytoriami jest podzielona na dwa etapy:
Kopiowanie nowych zatwierdzeń ze zdalnego oddziału do kopii tej zdalnej gałęzi wewnątrz lokalnego repozytorium.
(operacja repo do repo) master @ remote >> remote / origin / master @ local
Integracja nowych zobowiązań do lokalnego oddziału
(operacja wewnątrz repozytorium) remote / origin / master @ local >> master @ local
Istnieją dwa sposoby wykonania kroku 2. Możesz:
Rozwidlenie lokalnej gałęzi po ostatnim wspólnym przodku i dodanie nowych zatwierdzeń równolegle do zatwierdzeń, które są unikalne dla lokalnego repozytorium, zakończone scaleniem zatwierdzeń i zamknięciem rozwidlenia.
Wstaw nowe zatwierdzenia po ostatnim wspólnym przodku i ponownie zastosuj zatwierdzenia unikalne dla lokalnego repozytorium.
W terminologii git krok 1 to pobieranie git, krok 2 to git merge lub git rebase
git pull to git fetch i git merge
|
Git uzyskuje gałąź najnowszej wersji ze zdalnego na lokalny za pomocą dwóch poleceń:
Pobieranie git: Git pobierze najnowszą wersję ze zdalnego na lokalny, ale nie zostanie automatycznie scalony.
git pobierz wzorzec pochodzenia
git log -p master..origin / master
git merge origin / master
Powyższe polecenia oznaczają, że pobierzesz najnowszą wersję gałęzi głównej ze źródła z gałęzi zdalnej do gałęzi głównej. Następnie porównuje lokalną gałąź główną i gałąź główną pochodzenia. Wreszcie scal.
git pull: Git pobierze najnowszą wersję z pilota i połączy się z lokalnym.
git pull origin master
Powyższe polecenie jest odpowiednikiem git fetch i git merge. W praktyce git fetch może być bezpieczniejszy, ponieważ przed scaleniem możemy zobaczyć zmiany i zdecydować, czy scalić.
|
Jaka jest różnica między git pull i git fetch?
Aby to zrozumieć, musisz najpierw zrozumieć, że twój lokalny git utrzymuje nie tylko twoje lokalne repozytorium, ale także utrzymuje lokalną kopię zdalnego repozytorium.
git fetch aktualizuje lokalną kopię zdalnego repozytorium. Na przykład, jeśli Twoje zdalne repozytorium to GitHub - możesz chcieć pobrać wszelkie zmiany wprowadzone w zdalnym repozytorium do swojej lokalnej kopii repozytorium zdalnego. Umożliwi to wykonywanie operacji, takich jak porównywanie lub scalanie.
Z drugiej strony git pull obniży zmiany w zdalnym repozytorium do miejsca, w którym przechowujesz swój własny kod. Zwykle git pull najpierw wykona pobieranie git, aby zaktualizować lokalną kopię zdalnego repozytorium, a następnie połączy zmiany z Twoim własnym repozytorium kodu i prawdopodobnie kopią roboczą.
|
git pull == (git fetch + git merge)
git fetch nie zmienia się w lokalnych oddziałach.
Jeśli masz już lokalne repozytorium ze zdalną konfiguracją dla żądanego projektu, możesz pobrać wszystkie gałęzie i tagi dla istniejącego zdalnego za pomocą git fetch. ... Funkcja Fetch nie wprowadza żadnych zmian w oddziałach lokalnych, więc musisz scalić oddział zdalny ze sparowanym oddziałem lokalnym, aby uwzględnić nowo pobrane zmiany. z github
|
Prosta reprezentacja graficzna dla początkujących,
tutaj,
git pull
pobierze kodz repozytorium i rebase z lokalnym ... w git pull istnieje możliwość utworzenia nowych zatwierdzeń.
ale w ,
git fetch
będzie pobierał kod z repozytorium i musimy go ręcznie przebudować za pomocą git rebase
np .: zamierzam pobrać dane z serwera głównego i ponownie umieścić go w moim lokalnym serwerze głównym.
1) git pull (rebase zrobi się automatycznie):
git pull origin master
tutaj źródło jest twoim zdalnym repozytorium jest twoją gałęzią
2) pobieranie git (trzeba ręcznie ponownie bazować):
git pobierz wzorzec pochodzenia
pobierze zmiany serwera z pochodzenia. i będzie w twoim lokalnym, dopóki sam go nie przebudujesz. musimy ręcznie naprawiać konflikty, sprawdzając kody.
git rebase origin / master
spowoduje to zmianę bazy kodu na lokalny. przed tym upewnij się, że jesteś we właściwej branży.
|
Staram się być jasne i proste.
Polecenie git pull jest w rzeczywistości skrótem do git fetch, po którym następuje git merge lub git rebase, w zależności od konfiguracji. Możesz skonfigurować repozytorium Git tak, aby git pull było pobieraniem, a następnie ponownym bazowaniem.
|
W rzeczywistości Git przechowuje kopię Twojego własnego kodu i
zdalne repozytorium.
Polecenie git fetch aktualizuje lokalną kopię, pobierając dane ze zdalnego repozytorium. Potrzebujemy tego, ponieważ ktoś inny mógł wprowadzić pewne zmiany w kodzie, a Ty chcesz się na bieżąco aktualizować.
Polecenie git pull przenosi zmiany w zdalnym repozytorium do miejsca, w którym przechowujesz własny kod. Zwykle git pull robi to, wykonując najpierw „git fetch”, aby zaktualizować lokalną kopię zdalnego repozytorium, a następnie scala zmiany z własnym repozytorium kodu i prawdopodobnie kopią roboczą.
|
1
2
Kolejny
Bardzo aktywne pytanie. Zdobądź 10 punktów reputacji, aby odpowiedzieć na to pytanie. Wymóg dotyczący reputacji pomaga chronić to pytanie przed spamem i brakiem odpowiedzi.
Nie szukasz odpowiedzi? Przeglądaj inne pytania oznaczone tagiem git kontrola wersji git-pull git-fetch lub zadaj własne pytanie.